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INTRODUCTION 


There is a growing terest in moving toward more resource sharing 
on the ARPANET. Some resource sharing has been taking place by 
naving systems open TELNET connections and generating user command 
Strings. I think that this is fine for experimental use, but is 
not the Way we want to operate in real usage. What I believe 
network system builders should do is to develop mechanisms 
appropriately designed for computer-computer communication. 


SYSTEM INTERCONNECTION, AN APPROACH 


The goal I would like to see us move toward is to view all systems 
on the network as offering certain service modules, any subset of 
which can be combined in puilding other systems. Each service 
module would have a Well advertised set of primitive service 
capabilities that it could provide, It would have documented 
commands at the level of present Telnet or FTP commands for 
gaining access to its services. It would also have a defined 
network connection procedure, Then any system builder wanting to 
avail himself of these services could do so and integrate then 
into his own user interface environment. 


At the present time When a system is built, the system puilders 
tend to see it as a stand alone thing or at most something to be 
used within a specific environment. What I would like to see 
fostered is the idea that any system built is not only a stand 
alone environment but also a network Service or set of services. 
The builders would define not only a user interface for their 
environment, but also a set of primitives and primitive commands 
that can be accessed by other systems around the network to get 
that service performed, o 


For example, we are redesigning the NLS Journal in light of our 
experience and that of Network Mail aS a set of protocols and 
Services. If one looks at the processes of the NLS Journal one 
can see a number of Separate services that could be provided by 
different network sites or combined in varying combinations by 
‘a Single site. These being: 


Distribution (identification of addressees and maintainance 
of the required data bases being a related service), : 
recording (numbering and storing of items), cataloging, and 
retrieval. 
At the moment these services are fairly tightly interconnected in 
the NLS Journal and what we want to do is to decouple them and 
define their intercommunication by protocols that would allow then 
to be distributed in different hosts on the network. Mechanisms 
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would also be defined for the several hosts performing similar 
services around the network to work together cooperatively. 


AS a further example, there are also other Services that NLS could 
probably provide such as structured file creation and 
manipulation; information portrayal online or in hardcopy; 
database querying etc. However, at the moment the system is not 
explicitly structured from the point of view that outside systems 
could come into it anywhere but at the human user interface even 
though internally it is quite modular. It would be 
Straightforward for us to identify those NLS services that other 
system builders might possibly be interested in incorporating into 
their systems with their own user interface and then to do the 
restructuring and primitive command definition necessary. Other 
groups building systems on the network could perform a similar > 
examination. . l 


CCA, on the other hand as I understand it, has taken this point of 
view from the beginning, namely building the Datacomputer on the 
assumption tnat it is primarily a network resource and is to be 
usd by other systems, BBN iS also moving in this direction in the 
a@esign of Distributed TENEX. 


There is nothing new in the above ideas; they come from 
generalizing past successes We nave all had with network protocol 
Gevelopment and with good software engineering practices. It 
will, however, take a change in the thinking of system designers, 
some concrete examples, and ongoing dialog to make such a design 
philosophy the normal network way of life. 


SOME FUNCTIONS READY FOR INTERCONNECTION 


The area of dialog support may be the first area ripe to create 
such a synthesis with the several systems in or coming into 
existence, each solves part of the problem (with some overlap). 
The dialog support systems on the network Known to me ares 


The NLS Journal (supports recorded and cataloged dialog and 
linked networks of documents and messages). 


NLS Screen linking and splitting (Supports close collaboration 
of two or more people working together in real time in NLS) 


The network wide linking of terminals through BBN's RSEXEC. 


Tenex Sndmsg and Readmail and other mail systems support 
nonrecorded dialog and further manipulation of received 

_ messages. (Some interconnection between NLS and these 
facilities has been established). 
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The communication system under design at USCeISI to support a 
range of message services, 385 


The online conferencing system being built by Jim Calvin of 

Case, John Iseli of Mitre and others supports online 

conferencing of several members and has facilities to utilize 

various Tenex subsystems such as TECO and NLS to support 

conferees, 386 


The Hack system of CASE offers a bulletin board service. 3a7 


The Forum system of IFF supports online and distributed in time 
conferencing and other features. 3a8 


Other areas possibly ripe for synthesis are 1) file and data 

Management, and information retrieval services; 2) editing and 

hardcopy portrayal with systems like Tenex RUNOFF, SU-AI's PUB anda 
SRI-ARC'S Output Processor. , 3b 


If the salient service features, concepts, goals of each could be 
defined clearly and appropriate service primitives, as per other 
ARPANET protocols, could be defined for each, anyone wishing to 

incorporate that service with a user interface appropriate to his 


environment or philosophy could do so. 3c 
SYSTEM INTERCONNECTION ISSUES RELATED TO THE ABOVE PROPOSAL 4 

There are many detailed issues related to system interconnection 

aS proposed above. A number seem worth mentioning here. ha 

1) Types of Network Connections l i yb 


The number and type of network connections to be opened between 
Classes of cooperating processes can probably be systematized. 

One of the important elements of the FTP and Graphics protocol 

efforts Was to define the numper and type of connections 

necessary for these classes of transaction. Similar 

Classification and connection definition will be required for 

Other types of processes. bl 


2) Data Structure Translation l ke 


The whole area of translation and transfer of data structures 
more complicated than sequential files needs vigorous vhoirg ht 
and protocol development. hel 


Systems built around sequential files are presently dominant 
on the ARPANET and provide a base for simple useful 
economical tools. I, nowever, do not believe that the 
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3) 


4) 


5) 


6) 


7) 


8) 


longer run tool sharing can depend on communication between 
sequential files, but requires structured files, Experience 
with NLS tree structured files shows that even this level of 
structuring may be inadequate for many uses and more 
sophistication may be required. A Similar trend exists in 
work with computer graphics and generalized data management 
systems, Developing protocols for handling structured data 
bases or agreement on common structuring characteristics 
seems an important need. 


Responsiveness 


Factors influencing responsiveness to users in an environment 
of heavy geographically separated resource sharing need 
determination and discussion. 


Documentation of System Interfaces 


It is probably resonabdly straightforward to define service 
interfaces, but they will be useless unless their activating 
command languages and other conventions are well documented and 
this documentation is kept up to date. 


Accounting 


A very difficult problem once you interconnect systems at lower 
levels is to design an appropriate network accounting and 
banking system that will not cause undue delays in accessing 
distributed resources, 


Error Handling 


We need to develop mechanisms for paSsing error signals around 
When System environments are crossing machine boundaries. 


Standard Parameter Formats 


Data types such as strings, integers, floating point numbers, 
arrays, pointers, etc. need to have standard representations 
defined for passing parameters back and forth between machines. 


HELP at the Procedure Cail Level 


A HELP mechanism needs to be defined in the protocols to 
provide information that each designer can translate to his 
user interface. Standards for requesting HELP information and 
Structuring HELP data bases needs agreenent, 
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